Increasing demand for network services has led to many innovative techniques whereby multiple servers are clustered together in order to provide higher capacity and/or higher server availability. A cluster of servers can now masquerade as a single server from the perspective of a client system. Hence, as one client system accesses the cluster, it perceives only a single server and interacts with that server in a classic client-server relationship.
One of the services that a client depends on is that of access to remotely mounted volumes of data storage. One manner in which a single server provides this type of access is through a facility known as a network file system (NFS). An NFS facility allows a client to mount a volume of data storage and then access files on the mounted volume as though those files were local to the client. Since an NFS must be capable of supporting a plurality of client requests, a volume of data storage may be mounted by several clients. Hence, individual clients must contend for a remotely mounted volume provided by the NFS. One example NFS structure manages individual client requests for data at a file level. According to one example of an NFS system, a client requests access to a file. This is accomplished by interacting with a file lock manager, typically integral to the NFS system. Once the file lock manager grants access to a particular client, a file lock status manager (a process that monitors the activity of the lock manager) notes the existence of an active client file lock. One manner in which the lock status manager notes the existence of an active client file lock, according to one example NFS structure, is by creating a client file lock description file and placing the client file lock description file into a status directory.
This method for sharing files through file locks works well so long as the server providing the NFS functionality is truly a single server and not a server cluster as previously described. In the case where a server cluster is providing NFS functionality, the NFS functionality may migrate from one server platform to another based on availability of processing resources. Hence, where a client receives a file lock from an NFS's lock manager operating on one server in the cluster, that same file lock may not be recognized by an NFS lock manager operating on a different server in the cluster. This condition is problematic; especially when the client begins to interact with a different server in the cluster because the primary server can no longer provide NFS functionality to that client (i.e. the service function has migrated to a different server). This different server is normally referred to as an “adoptive” server.
The problem is somewhat exacerbated by the fact that the client remains blissfully unaware that it is now interacting with a different server platform within the server cluster. Hence, the client may attempt to access a file on a remotely mounted volume using what it perceives to be a valid client file lock. The NFS lock manager operating on the adoptive server will not honor a file access request from the client because it is not privy to the client file lock granted by the lock manager operating on the first (i.e. primary) server.